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VMEbus Implementation Summary 


This document is intended to provide customers of Sun Microsystems with all 
the information needed to attach devices to the Sun-3/100 VMEbus, including 
programming and hardware design considerations. It is not intended to explain 
to VMEbus per se, as it assumes a working knowledge that can be derived from 
studying the VMEbus Specification, available from Motorola Semiconductor Pro- 
ducts, Inc. 

Table 1-1 Master Capabilities 


Data Bus Size: 

D32 MASTER 32/16/8 bit data 

Address Bus Size: 

A32 MASTER (DYN) 32/24/16 bit 
addresses 

Timeout Option: 

TOUT (737) 737 microsecond 
timeout period 

Sequential Access: 

None 

Interrupt Handler: 

IH(1-7)(STAT) Level 1 thru 7. 
independently jumpcrablc. All 
interrupts use vectors provided by 
VMEbus interrupters, per the VME 
spec. 

Requestor Option: 

ROR R(3) Release On Request, 
level 3 

Bus Busy Option: 

Releases BBSY after AS assertion 
when releasing bus 

Read/Modify/Write: 

Will not release VMEbus during 
read/modify /write cycles. RMW 
instructions must not be used while 
DVMA is occurring, as the 68020 
.will not relinquish and retry on 
deadlocks during RMW cycles and 
cause timeout bus errors. 


NOTE ■ Address strobe is negated between the read and write portion. 1 ; of R\t »' cycles. .v,> 
the Sun-3/ 100 does not use RM\v cycles as defined in the VMEbus Specification 
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Table 1-2 Slave Capabilities 


Data Bus Size: 

D32 SLAVE (DYN) 32/16/8 bit daia 

Address Bus Size: 

A32 SLAVE (DYN)32/24 bit 


addresses (no 16-bit addresses) 

Sequential Access: 

None 

Special Access Mode: 

A high-speed access mode (Lock 
Mode) is engaged if the time from 
DTACK assertion to the next AS & 
DS assertion is less than 200ns 

Interrupter Options: 

None 

32-bit Slave Addressing: 

The Sun-3/100 responds to the bot- 
tom 1 MB by performing DVMA 
using system function codes and 
responds to the top 2 GB by per- 
forming DVMA using user function 
codes. Response can by dynamically 
disabled on 256 MB boundaries. 

24-bit Slave Addressing: 

The Sun-3/100 responds to the bot- 
tom Mb by performing DVMA 
using system function codes. 


Table 1-3 System Controller Capabilities 


Clock Option: 

SYSCLK 16 MHz. 
jumperable (not used 
onboard) 

Arbiter Option: 

ONE bus request/grant 
level 3 only - or external 
arbiter 

Bus Timeout Module: 

None 

Sysreset Option: 

SYSRESET MASTER or 
SYSRESET SLAVE, incl. 
manual button 

AC Fail Option: 

Not implemented 
(ACFA1L is connected to 
SYSRESET) 
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Table 1-4 


Table 1-5 


Table 1-6 


NOTE 


4 


Environmental Characteristics 


Operating Temperature: 

10 - 40 deg C 

Humidity: 

5 - 90% non-condensing 


Power Considerations 


+5 Volts: 

14 Amp maximum 

-5 Volts: 

1 Amp maximum 

+12 Volts: 

0.5 Amp maximum 

-12 Volts: 

Not used 


Typical Sun-31100 Performance Parameters 


Parameter 

Sun-2 

Sun-3/100 Measured 

Notes 

CPU to VME Latency 1 

468 ns 

381 ns 

1 

CPU to VME Latency 2 

264 ns 

186 ns 

2 

CPU to VME Bandwidth 

3.3 MB/sec 
606 ns 

9.5 MB/sec 
420 ns 

3 

VME to P2 Latency 

952 ns 
1020 ns 

743 ns 
510 ns 

4 

VME to P2 Bandwidth 

1.97 MB/sec 

7.84 MB/sec 

5 

Time to Acquire VME 

162-264 ns 

141-191 ns 

6 

CPU-to-CPl) Bandwidth 


3.44 MB/sec 
1163 ns 

7 

UNIX Throughput 

310KB/scc 

704 KB/sec 

8 

Astraca Bd. Throughput 


2.8 MB/sec 

9 

Xylogics Throughput 


1.41 MB/sec 
1420 ns 

10 

GP Cycle Time 


1 200 ns 

11 j 

Lock Mode Throughput 


600 ns 
6.67 MB/sec 

12 ; 

Lock Mode Latency 


440 ns 

13 ! 
1 


Unless otherwise noted, the Sun-2 numbers arc estimates fur a Sun-2: 50 worksta- 
tion. 

The following numbered notes give more detail on the parameters from the table 
above and arc referenced by the column, “Notes." 
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1. Measured from processor address strobe to vme DTACK with an ideal vme 
device, with the CPU not currently bus master. Unless otherwise noted, 
measurements are the average of 10 samples on a logic analyzer with a 10 ns 
resolution. 

2. Measured same as above, but CPU currently bus master. 

3. Assumes an ideal 32-bit data vme device. 

4. Measured from VME address strobe to VME DTACK. 

5. Assumes P2 bus is locked, allowing a 65 ns negation period on vme address 
strobe. The Sun-3/100 measured number is extrapolated from actual meas- 
ured d ata, as we currently do not have VMEbus masters this fast 

6. Measured from assertion of VME bus request to assertion of vme bus grant 

7. One Sun-3/100 is not fast enough to engage lock mode on a second Sun- 
3/100. The estimated number is derived from analysis of the schematic. 

8. Command used is cp filename /dev/null, file size is 10 MB. Both disks were 
Fujitsu Eagles; disk controllers were Xylogics, with the Sun- 3/1 00 using a 
VME-Multibus adapter. The Sun-2 was a 2/120 system. 

9. The Astraea board is a 256 KB memory board with a response time from 
VME DTACK of 279 ns. Test was a hand-assembled tight loop writing over 
the VMEbus to the Astraea board. The estimated number is from analysis of 
the schematic, combined with the information about the response time of the 
Astraea board. 

10. Estimated from observation of oscilloscope traces. There were four distinct 
cycle times: 1300, 1400, 1500, and 1600 ns. Transfers were from disk to 
onboard memory. 

11. Graphics processor (GP1) as Master and Sun-3/100 as Slave. 

12. Using graphics processor modified to automatically start a cycle 60 ns after 
ending previous cycle. 

13. Measured from VME address strobe to DTACK. 
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Latency 


2.1. Latency 

Considerations 


Latency, in this case, is the time elapsed between when an external vme master 
requests a cycle and when the Sun-3/100 board responds to that cycle. This 
latency can be divided into four separate periods: 

a The time required to get control of the local bus from the current mas- 
ter. 

□ The time required to get control of the local bus from the CPU; 

o The time required to perform any pending DMA of higher priority; 

o The time required to perform the cycle. 

The VMEbus has no specified time that a master may keep control of the bus after 
another master has issued a bus request, but the Sun-3/100 will release the bus as 
soon as it completes the cycle that may be in progress when the bus request 
arrives. The worse-case situation is when the bus request arrives just after state 3 
of a CPU access of the VMEbus, because at that point, it is committed to perform a 
vme cycle. At state 5 it will assert vme address strobe; at state 7 it will be syn- 
chronized; and at state 9 it will assert vme bus grant — for a total worst-case 
elapsed time of 232 nanoseconds. Masters other than the Sun-3/1 00 board may 
keep control of the bus for an arbitrary length of time. One example is the Xylo- 
gics disk controller board, which has been observed to keep control of the bus for 
over 45 microseconds after bus request has been asserted. 

The external master is now required to wait until the vme address strobe is 
negated before it can take control of the VMEbus, which can only happen after the 
currently addressed slave responds with vme DTACK. The VMEbus has no 
specified maximum response time either, so this can be an indeterminate period. 
In a Sun system the worst case response time is that of the Xylogics disk con- 
troller board, which can take up to 70 microseconds. 

Once the vme address strobe goes away, the external master can take control of 
the VMEbus, enable its addresses and data onto the bus. and assert its own address 
and data strobes. These addresses and strobes arc decoded on the Sun-3/100 
board to form an onboard request called XREQ. 

The worst-case time to acquire the local bus is when XREQ arrives just as the CPU 
stans a cycle to a slow onboard device such as an interrupt acknowledge to the 
vectored serial pons, which takes up to 1170 nanoseconds. This time will add to 
the time required to decode the VMEbus addresses and generate XREQ. w hich is 
1 80 nanoseconds if the vme address strobe exactly misses a CPU synchronization 
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clock, for a total of 1350 nanoseconds. 

If sometime during that 1 170 nanoseconds when waiting for the local bus, a DMA 
request from the Ethernet interface is received, it will be serviced first This will 
require approximately 500 nanoseconds to complete, during which a refresh 
request might be received. The latter request will require another 300 
nanoseconds and may give the Ethernet interface enough time to turn around and 
request another DMA cycle, giving another 500 nanosecond delay. At this point 
the VME slave cycle is assured of service. Thus, the total worst- case wait to 
acquire the local bus is 2.65 microseconds. 

The final component of the Sun-3/100 slave response time is the actual time 
needed to perform the memory cycle and generate a VME DTACK, which in the 
c ay of a main memory cycle is 330 nanoseconds. Therefore, the total time, 
under the absolute worst-case conditions, to acquire the VMEbus and perform a 
memory cycle on the Sun-3/100 board is 3.21 microseconds, not counting the 
time required for a board that may currently be master to finish its cycles and 
relinquish the VMEbus. 
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Throughput Considerations 


3.1. Lock Mode Lock Mode prevents the CPU from using its local bus and is engaged when the 

turnaround time of the external VME master is less than 200 nanoseconds from 
when the Sun- 3/1 00 board asserts VME DTACK to when the external master 
asserts vme address and data strobes for the next cycle. As long as this situation 
occurs at the end of each slave cycle, the CPU local bus will remain locked for 
another cycle. 

During Lock Mode, refresh and Ethernet DMA cycles will continue to occur, as 
they have a higher priority than pending vme slave cycles. In addition, the CPU 
will be allowed to perform one bus cycle after each refresh if it necessary, so it 
can continue to limp along even if the Lock circuitry becomes defective, or if an 
external master keeps Lock Mode engaged for a long time. 

If a vme master device is designed specifically to use Lock Mode, it is preferable 
that it limit Lock Mode transfers to 16 in a row and then back off long enough to 
allow the CPU to perform a cycle. This is not a requirement, however, as generic 
boards might be able to engage Lock Mode. The 200 nanosecond figure is also a 
worst-case figure; for example, if the turnaround time is less than 200 
nanoseconds. Lock Mode is guaranteed to become engaged. If turnaround time 
is between 200 and 240 nanoseconds. Lock Mode might be engaged. Lock Mode 
transfers arc shown in Figures 3-1 and 3-2. 

The throughput number given above assumes no Ethernet activity. If the Ether- 
net interface is attempting to perform DMA cycles at the same time as the vme 
slave interface, the slave interface will slow down. The Ethernet operates at 10 
megabits/second, or 1.25 megabytes/second and takes an additional lOfr for 
overhead such as fetching command blocks, buffer descriptors, anu so on. for a 
total bandwidth requirement of 1.37 megabytcs/sccond. Subtract 1.37 
MB/scconds directly from the 7.84 MB/sccond figure provided in Table 1-6 for a 
figure of 6.46 MB/scconds through the VME slave interface when Ethernet is 
active. 

3.3. Throughput Lost to A refresh cycle is performed every 15 microseconds, taking approximately 300 

CPL and Refresh nanoseconds away from the time available for the vme slave interface. This 

represents a 2% overhead, fora loss of 0.16 MB/sccond. In addition, as men- 
tioned above, the CPU is allowed to perform one bus cycle after every refresh 
cycle. If it takes advantage of this opportunity, the cycle will take 270 
nanoseconds. Four clocks will be wasted in turning mastership of the bus over to 


3.2. Throughput Lost to 
Ethernet 
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the CPU and regaining it after the cycle, for a total loss of 5 10 nanoseconds. This 
3.4% overhead adds to the time taken for the actual refresh cycle of 2%, giving 
an overhead of 5.4%, or 0.42 MB/seconds. To a first approximation, this loss is 
additive to the Ethernet loss described in the previous section, so that the worst- 
case throughput of the VME slave interface is 6.04 MB/second, when Ethernet is 
active over a long period. 

3.4. Throughput Lost to In reference to note #5 from the table. Typical Sun-31100 Performance Parame- 

Turnaround Time ters, the master is allowed a 65 nanosecond negation period on the VME strobe. 

If the negation period is longer, perfonnance will suffer in increments of 60 
nanoseconds per cycle, up to the point where the turnaround time is so slow that 
Lock Mode is no longer engaged. At that point, the CPU will start performing a 
memory cycle after each VME slave cycle, so two kinds of overhead will be 
incurred: the first is due to the actual time taken to perform the CPU cycle, and the 
secon d is due to time wasted in transferring the local bus back and forth between 
masters. This overhead amounts to 6.5 clocks, lowering the throughput from 
7.84 MB/seconds to 4.17 MB/seconds. See Figure 3-3. 
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Figure 3-1 Lock Mode Engagement 


XR EQ- is low when the following conditions are true: 
VME Address Strobe 
& VME Data Strobe 0 or 1 
&. Correa Address Decode 
&. DVMA is enabled 

X.DMAEN- is low during VME DVMA Cycles 



X.DMAEN- f 


H* 5 Clocks 

VME DTACK- 3 sSi 

\ * 

\ • 

\ / 

VME Data Strobes- I 


VME Address Strobe- I 


VME Addresses VWM Dr.hnarri A 


XREQ- 

Lock Mode- 



Toial "window" for engaging Lock Mode is 5 clocks, or 300 ns. 
From this wf must subtract several propagation delays, 
so that only 200 ns is left for the specified period from 
our assertion of VMEDtack to their assertion of VME 
Address Strobe and at least one VME Data Strobe. 


Lock Mode Engagement 
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Figure 3-2 VME Device Initiates P2 Bus Lock 
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Timing 


The Sun-3/100 implements the full Motorola VMEbus Specification , Revision B, 
with no exceptions. Any board designed to meet the VME spec should plug right 
in. Nevertheless, in this section we provide the minimum/maximum timings for 
all signals on the VMEbus in both master and slave modes. See also Figure 4-1, 
which accompanies Table 4-1 — Master Timing and Figure 4-2, which accom- 
panies Table 4-2 — Slave Timing . 


T able 4- 1 Master Timing 


VME Spec# 

Description 

Min (ns) 

Max (ns) 

VME Spec (ns) 

1R 

Axx and AMx valid to AS* low 

38 

82 

38 

2R 

DTACK low to invalid address 

137 

? 

0 

3R 

AS* high 

188 

7 

40 

4R 

DTACK low to AS* highf 

137 

294 

0 

5R 

AS* to DS “A” skew 

7 

30 

0 

6 R 

WRITE* valid to DS “A” low 

38 

82 

35 

7R 

DS “B” high to invalid WRITE* 

10 

7 

10 

8 R 

DATA release to DS “A” low 

150 

7 

0 

9R 

DS “A” to DS “B” skew 

0 

8 

10 

9W 

Dxx valid to DS "A” low 

38 

97 

35 

10R 

DTACK* low to DS “A” high* 

137 

244 

0 

10W 

DTACK* low to invalid data 

137 

227 

0 

hr 

DS “A” high 

168 

7 

40 

12R 

DS “B” to DS “A” low 

168 

7 

40 

13R 

DTACK*/BERR* high to DS “A” low 

15 

7 

0 

14R 

DTACK* low to DS “B” high* 

137 

244 

0 

16R 

DS “B” high 

168 

7 

40 


*Lf DTACK arrives within 2.88 microseconds; otherwise majx=2560 


iSce 4R m above Lablc. 
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Table 4-2 Slave Timing 


VME Spec# 

Description 

Min (ns) 

Max (ns) 

VME Spec (ns) 

15W 

DS “A** low to DTACK*/BERR* low 

352 

2980 

30 

16R 

Data valid to DTACK* low 

65 

125 

0 

18R 

DS "A” high to invalid data 

17 

67 

0 

20R 

DS “B” high to DTACK*/BERR* high 

12 

50 

0 
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The Arbiter/Requestor is a synchronous state machine responsible for granting 
control of the VMEbus to the CPU while holding off other devices wishing control 
of the VMEbus and to grant control of the VMEbus to external vme devices when 
the CPU doesn’t wish to to access it. The arbiter and requestor functions could be 
implemented as separate modules, but this was not done since separating the 
functions introduces extra states into the request process, slowing it significantly 
and increasing the chip count. 

The arbitration function can be locked out by moving jumper J2701 to J2700, in 
case you wish the function to be performed on a separate board. You can install 
two or more Sun-3/100 boards in the same system for testing. Moving this 
jumper leaves the board operating only as a VMEbus requestor, as described in the 
VMEbus manual. 

42 . Master Addressing During master cycles the addresses presented on the VMEbus are physical — the 

addresses have already been translated by the Memory Management Unit. Two 
bits called type 0 and type 1 come out of the MMU to differentiate whether a 
given physical address is on the CPU board or on the VMEbus. If it is on the 
VMEbus, the bits tell you whether it is in the 16 or 32-bit data space. Note that 
the type 0 and 1 bits give four complete 4 gigabyte address spaces: 

□ Onboard memory; 

o Onboard input/output devices; 

o 1 6-bit data VME devices; 

a 32-bit data VME devices. 

Address space is further expanded by decoding separate CPU space, control space, 
and device space. However, all physical addresses reside in the device space. 

Accesses to the 32-bit data space will only be performed as vme long-word 
accesses if the address is long-word aligned, and the size of the cycle is long- 
word, as indicated by the 68020-size bits. Othcrwise.the cycle will be broken 
down into the appropriate number of byte and word accesses to the proper 
addresses, using the dynamic bus-sizing feature of the 68020. The vme 
Specification , Revision C was generalized to allow non-aligned 3-byte transfers, 
but the Sun-3/100 board docs not use this feature. 

Both of the vme spaces arc further decoded to handle devices that respond only 
to 16-bit addresses, or the full 32-bit addresses. The top 16 megabytes of each 
address space is reserved for 24-bit address devices, except for the top 64 kilo- 
bytes, which is reserved for 16-bit address devices. This allows the Sun-3/ 100 
board to access devices designed to use any combination of data and address 
widths. The number of address bits valid for the current cycle is indicated by the 
VME address modifiers, while the width of the data transfer is indicated by the 
VME LWORD signal and data strobes, as discussed in the vme Specification. 

The address map described above is shown in Figure 4-3. 


4.1. VME Arbiter and 
Requestor 
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Figure 4-3 Physical Address Mapping 
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4.3. Long Master Cycles If the response time of a vme slave device is longer than 2.88 microseconds, the 

Sun-3/100 board can react slower to a DTACK from the slave, due to the way the 
Sun-3/100 board allows for long response times from vme slaves. Since the vme 
specification has no limit on the response time, it is necessary to implement a 
reasonable maximum. The difficulty is that main memory refresh cycles and the 
Ethernet interface operate under real-time constraints, so they must not be forgot- 
ten during long vme cycles. After 2.88 microseconds, the Sun- 3/1 00 board 
assumes that the addressed device is very slow and only comes back periodically 
to check whether a response has been received from the device. Meanwhile, any 
pending refreshes or Ethernet cycles are performed. 
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Address Modifiers 


5.L Address Modifiers on The address modifiers on the VMEbus provide additional information about the 
Master Cycles nature of the cycle, such as the number of valid address bits and the type of pro- 

tection that should be applied to the current cycle. The Sun-3/100 implements 
the address modifiers as shown in the following table: 


Table 5-1 Address Modifier Codes 


Address 
Modifier 
54321 0 

Function 

Hex 

Code 

001001 

32-bit addressing — user data space 

09 

001010 

32-bit addressing — user program space 

0A 

001101 

32-bit addressing — supervisor data space 

0D 

001110 

32-bit addressing — supervisor program space 

0E 

101001 

16-bit addressing — user data space 

29 

101010 

16-bit addressing — user program space 

2 A 

101101 

16-bit addressing — supervisor data space 

2D 

101110 

16-bit addressing — supervisor program space 

2E 

111001 

24-bit addressing — user data space 

39 

111010 

24-bit addressing — user program space 

3A 

111101 

24-bit addressing — supervisor data space 

3D 

111110 

24-bit addressing — supervisor program space 

3E 

1 


5.2. Slave Addressing 


The slave interface on the Sun-3/100 board has two operating modes, known as 
Supervisor DVMA and UscrDVMA.. Direct Virtual Memory Access is Sun's tra- 
demarked method of allowing DMA devices to use virtual addrcssscs instead of 
the usual physical addresses, "saving software and hardware from the overhead of 
translating the addresses separately for the DMA devices. The vinual addresses 
from the VMEbus arc translated by the Sun-3/100 MMU into physical addresses, 
just like the addresses from the CPU. 

Supervisor DVMA corresponds to that which was available on the Sun-2 CPU 
boards: a one megabyte window into vinual memory, with DMA performed by 
using supervisor function codes. User DMA is an extension, new to the Sun-3/! 00 



21 


Revision A of 24 November 1 U S“ 




22 User’s Guide to the Sun-3/100 VMEbus 


architecture, and allows VME devices to access the entire 256 megabyte virtual 
address space of the CPU in each of the eight contexts. Programs running on the 
CPU can share pointers to data at arbitrary locations with coprocessors located on 
the VMEbus, greatly simplifying the task of sharing data between the two proces- 
sors. Supervisor DVMA is performed if the address on the VMEbus is in the bot- 
tom megabyte of either the 24 or 32-bit VME address space, and if the Supervisor 
DVMA Enable bit in the System Enable Register is high. If the enable bit is low, 
the Sun-3/100 board will not respond. The board makes no distinction between 
Supervisor DVMA in 24-bit and 32-bit address spaces. 

The Sun-3/100 board responds in UserDVMA mode to VME addresses in the top 2 
gigabytes of the VME 32-bit address space, which requires VME address bit 31 to 
be high. User DVMA is performed with user function codes, so that it occurs with 
the full protection of the memory management unit VME address bits 28-30 
correspond to the context bits; when address bits are all low, context 0 is 
addressed. Contexts are individually enabled by bits in the UserDVMA Enable 
Register. If the context corresponding to the address currently on the VMEbus is 
not enabled, the Sun-3/100 board will not respond. Up to eight of the CPU boards 
may share the same backplane as long as only one context is enabled on each 
board. 

Slave address mapping is shown in Figure 5-1. 
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Figure 5- 1 VMEbus Slave Address Mapping 
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XXFFFFFF 


FFFFFFFF 


XXOFFFFF 

XXOOOOOO 


FFFOOOOO 


Context 7 


FOOOOOOO 


Context 6 


EOOOOOOO 


Context 5 


DOOOOOOO 


Context 4 


cooooooo 


Context 3 


BOOOOOOO 


Context 2 


AOOOOOOO 


Context 1 


90000000 


Context 0 


Supervisor 
Function Codes 



User 

Function Codes 
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5.3. VME Option Jumpers 

Interrupts The seven levels of interrupts from the VMEbus are individually jumperable, sub- 

ject to the VME Specification requirement that an Interrupt Handler Module must 
respond only to a contiguous range of interrupt levels. • The jumper that handles 
interrupt levels is J300, located at coordinate R-5 on the CPU board, shown in 
Figure 5-3. A level is enabled when the jumper is installed. 

The Sun-3/100 board can also be jumpered to be the VME reset slave, instead of 
the master, as is default. At the factory, the CPU is jumpered as the vme arbiter 
and requestor, but you can change the setting to vme requestor only. These func- 
tions are controlled by jumpers J2700-2703 at location R-12, shown in Figure 5- 
2 . 

In order to insert more than one Sun-3/100 board into the same backplane, the 
VME clock driver must be disabled in all but one of them. This function is 
enabled by jumper J2502, at A-3, shown in Figure 5-2. 

For further information about jumper options, consult the Sun 3004 CPU Board 
Configuration Procedures, P/N 8 1 3-2047. 
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More Timing Diagrams 


Figure A-l 


CPU Access of Idle VMEbus 

01 23 4 5 6 7 8 9 1011 1213 0 1 
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USER’S GUIDE TO THE SUN-3/100 
VMEBUS READERS COMMENT 

SHEET 

Dear Reader, 

We who work at Sun Microsystems wish to provide the best possible documenta- 
tion for our products. To this end, we solicit your comments on the User’s Guide 
to the Sun- 3/1 00 VMEbus. We would appreciate your telling us about errors in 
the content of the manual, and about any material that you feel should be there 
but isn’t. 

Please list typographical errors by page number and actual text of the error. 


Please list errors in technical accuracy by page number and actual text of the 
error. 



USER’S GUIDE TO THE SUN-3/100 VMEBUS READERS COMMENT SHEET 


Content 


Layout and Style 


Did this guide meet your needs? If not, please indicate what you think should be 
added or deleted in order to do so. Please comment on any material that you feel 
should be present but is not Is there material found in other manuals that would 
be more .convenient if it were in this manual? 


Did you find the organization of this guide useful? If not, how would you rear- 
range things? Do you find the style of this manual pleasing or irritating? What 
would you like to see different? 


Mail this completed form to: 

Manager, Hardware Technical Publications 
Sun Microsystems, Inc. 

2550 Garcia Avenue 
Mountain View, CA 94043 



